home *** CD-ROM | disk | FTP | other *** search
/ Turnbull China Bikeride / Turnbull China Bikeride - Disc 2.iso / BARNET / FREENET / BRODIE / FREESMTP.ZIP / ReadMeNow!
Text File  |  1998-08-02  |  36KB  |  892 lines
  1. !FreeSMTP 1.37
  2. ==============
  3.  
  4. Contents:
  5.     Copyright & Disclaimer
  6.     Important Changes in this Version
  7.     Installation Instructions
  8.     Upgrading from Earlier versions
  9.     Configuration Instructions
  10.         Why does all email get sent to "localhost"
  11.     Operating Advice
  12.         for people with permanent links
  13.         for people with transient dialup links
  14.     Running & Stopping !FreeSMTP
  15.     What to do if you get the error message:
  16.         Loopback interface is not configured/up
  17.         Loopback interface is configured - but not up
  18.     Kicking the sender
  19.     Activity log
  20.     References
  21.     Bug Reporting
  22.     Technical Details
  23.         MX records explained
  24.         Security Considerations
  25.         Ident
  26.     ChangeLog
  27.  
  28.  
  29. **** WARNING: Incorrect configuration can cause you to be in breach
  30. **** of your provider's terms & conditions.  Full details under the
  31. **** configuration section below, in the subsection "forwarder"
  32.  
  33.  
  34.  
  35.  
  36. Copyright & Disclaimer
  37. ----------------------
  38.  
  39. This program is copyright (C) Stewart Brodie, 1996, 1997, 1998
  40.  
  41. The author accepts no liability for any damage or loss of any kind incurred
  42. or allegedly incurred by the use or misuse of this software.  The program
  43. may do its absolute best to ensure that incoming mail is either stored
  44. successfully in the incoming (or outgoing) mail spool appropriately or that
  45. the sender is informed that the delivery attempt was unsuccessful and should
  46. be retried (or not as appropriate).
  47.  
  48. Having said all that, I do want people to use it and find any problems.  I'm
  49. afraid that some people's attitude make all those disclaimers necessary.  For
  50. normal usage, there shouldn't be any problem, and the programs try very hard
  51. indeed to prevent any loss occurring (eg. by not acknowledging successful
  52. reception of an e-mail until it has been successfully stored in the spool
  53. directory completely).  If the program fails, then in the vast majority of
  54. cases the upstream SMTP will have received a rejection from this program
  55. (unrequested connection termination counts as a rejection unless the 250
  56. response to the final '.' of a DATA body is received at the sender).  If the
  57. sender half of this software fails, then it it will construct a failure
  58. message and return that directly to the message originator.
  59.  
  60. This software is nothing whatsoever to do with my employers (currently Acorn
  61. Computers Ltd, of Cambridge, England) but is released with their permission.
  62. Acorn Computers Ltd. makes no claim over this version of the software.
  63.  
  64.  
  65.  
  66. Important Changes in this Version
  67. ---------------------------------
  68.  
  69. Time string calculation was double-adjusting for the timezone offset.  This
  70. is now corrected.
  71.  
  72.  
  73. Installation Instructions
  74. -------------------------
  75.  
  76. Installation should be fairly simple and trouble free provided these
  77. instructions are followed carefully.  You will NEED Newsbase 0.55 or later
  78. in order for this to work properly - it will not like 0.54.  I have tried
  79. to include as much details as possible, so don't worry about the apparent
  80. length of it.
  81.  
  82. * Copy the Transports directory into the !NewsDir.Newsbase directory to
  83. install the interface programs in Newsbase. (You may find that you have to
  84. restart Newsbase now to get it to recognise the newly present transport).
  85.  
  86. * Delete any old !Newsbase.Transports.in_smtpd directory.
  87.  
  88. * Copy the !FreeSMTP directory into a directory containing your other
  89. Internet applications, and run it in its new home (it will fail to start
  90. because there is no configuration file, but this step is necessary in
  91. order to reset the system variables to point to the correct directory)
  92.  
  93. * Open the Newsbase Transport Control window, and in the middle portion
  94. of this window, choose "in_smtpd" off the Transport menu.  You should now see
  95. the description "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)" or similar.  If
  96. you fail to get this far, then you may have forgotten to restart Newsbase or
  97. to rerun !FreeSMTP.
  98.  
  99. * Switch on the Check arrivals new mail option.
  100.  
  101. * Follow the instructions in the Configuration Instructions below
  102.  
  103. * Ensure you have a DNS resolver configuration file.  If you do not have a
  104. DNS resolver installed on your system, then you will need to get one.  You
  105. can find this out by looking for a file in !Internet.Files (or
  106. !FreeUser.Files or !InetSuite.Internet.Files) called "resconf".  If this is
  107. present, then you have already got the necessary file installed.  The
  108. resolver module is NOT used, but the configuration file it uses IS used by
  109. these programs (FreeNet (by Tom Hughes) comes with InetDB and its
  110. installation instructions; ArcWeb (my program) comes with just the
  111. installation instructions necessary).  Acorn Internet software installs
  112. system variables which are automatically picked up by FreeSMTP.
  113.  
  114.  
  115. Upgrading from Earlier versions
  116. -------------------------------
  117.  
  118. Reinstall the Transports into !NewsDir.Newsbase and delete any old ones
  119. in !Newsbase.Transports.in_smtpd.
  120.  
  121. Your mail is received into a different directory than before version 1.14.
  122. This makes it compatible with the KA9Q directory structure.
  123.  
  124. You should read the section on killfiles as version 1.34 and later contain
  125. a new form of mailkill which you may wish to use.
  126.  
  127.  
  128. Configuration Instructions
  129. --------------------------
  130.  
  131. There is a single configuration file for !FreeSMTP which is stored
  132. inside the !FreeSMTP directory.  This is deliberately entirely made
  133. up of comments so that the programs will refuse to load before you
  134. have edited the configuration.  You should find that you can skim
  135. through this section, modifying the file as you go.
  136.  
  137. (If !FreeSMTP.smtp-conf does not exist, then either copy it from defaultcnf
  138. in the same directory, or click on Setup in the Newsbase Transport Control
  139. window which will do this for you)
  140.  
  141. The configuration file is a sequence of directives which tell the
  142. software what your machine's real name is, what e-mail domains it
  143. hosts, and which domains it relays mail for (if any).  I have tried
  144. to provide as much flexibility as possible whilst keeping it as
  145. simple as possible for the vast majority of cases (take a look at an
  146. /etc/sendmail.cf file on a UNIX system to see how hairy it can become :-)
  147.  
  148. To edit the configuration file, choose the "in_smptd" transport in the
  149. Newsbase "Transport Control" window.  You should then see the description
  150. message "SMTP for FreeNet/Acorn TCP/IP (S.N.Brodie)".  To set up the Newsbase
  151. bit, ensure that "Check arrivals: new mail" is set; Route outgoing mail is
  152. set, and a smarthost is placed in the gateway box for mail(**).  Also set
  153. in_smtpd as the Def mail route.  Then, you should click on the Setup button
  154. which will open the configuration file in your text editor ready for you
  155. to set your own site details.
  156.  
  157. (**) If you set the gateway to be your own machine, then you MUST have
  158.      an appropriate forwarder line as described below.  The line you
  159.      will need will be "forwarder * provider's-smarthost".
  160.  
  161. Provided you have set up the forwarder lines, you can tell any software
  162. you have to send outgoing mail to 'localhost'.  This will result in it
  163. being sent to the server which will then route it using the rules in
  164. smtp-conf without consulting Newsbase.
  165.  
  166. There are brief comments in the configuration file to remind you what each
  167. section is for, but these are elaborated here.  The order of the sections is
  168. not important, although the order of declarations of the same type IS
  169. important (see below for reasons) For each section I have given the syntax,
  170. an example for a Demon DialUp user with a nodename of 'customer', (applicable
  171. to other static IP single host systems too), an example for a host on a
  172. network handling mail for that network, and my own setup when I was at the
  173. University of Southampton.  If you are on a dynamic IP system, you may need a
  174. script to automatically rewrite the configuration file if you are going to
  175. use FreeSMTP - although it is less likely that you will be using SMTP for
  176. mail reception on a dynamic IP node.
  177.  
  178.  
  179. hostname
  180. ========
  181.  
  182. Syntax:   hostname <Fully Qualified Domain Name (FQDN)>
  183. Demon DU: hostname customer.demon.co.uk
  184. Network:  hostname mail.an.org.uk
  185. My Setup: hostname delenn.ecs.soton.ac.uk
  186.  
  187. This gives the *full* hostname(s) of the machine running this software.
  188. Hosts may have more than one name in some circumstances, and this is
  189. allowed by having multiple hostname lines, although the *first* line
  190. found in the file is the one used to identify the server to remote
  191. hosts when it needs to (eg. when greeting SMTP clients)
  192.  
  193. localdomain
  194. ===========
  195.  
  196. Syntax:   localdomain <Fully Qualified Mail Domain> [<alias name>]
  197. Demon DU: localdomain customer.demon.co.uk
  198. Network:  localdomain an.org.uk
  199. My Setup: localdomain delenn.ecs.soton.ac.uk soton
  200.  
  201. [and in My Setup, <SMTPServer$Aliases>.soton contains the line:
  202. S.N.Brodie snb94r
  203. ]
  204.  
  205. This gives the local *mail* domain(s) handled by the software.  These
  206. mail domains are the things you see after the @ in mail addresses.
  207. When mail arrives, the destination is checked to see if there is any
  208. @ character in it.  If there is NOT, then the value of the *first*
  209. localdomain directive is assumed.  (This is so that the alias and user
  210. list functions can determine which set of aliases to apply)
  211.  
  212. Next, the bit after the @ is compared against each localdomain directive in
  213. turn.  If it matches any one of them, then the domain part is dropped. Next,
  214. if an alias name was specified for that localdomain, then the bit before the
  215. @ is looked up in <SMTPServer$Aliases>.aliasname to see if was a mail alias,
  216. and if so, the mail address is rewritten to match the definition of the
  217. alias.  The format of that file is described below.  You MUST be careful with
  218. that file.
  219.  
  220. Otherwise, the bit before the @ is assumed to be a mailbox in the local
  221. Newsbase. (If no domains match, then it is checked against the forwarders
  222. below).
  223.  
  224. If you wish to have an mailbox name that contains characters illegal in RISC
  225. OS filenames, then you can create an alias to convert it to something else,
  226. like I do in my alias file as shown above.
  227.  
  228. For single dialup hosts, there is likely to be a single setting which
  229. will happen to co-incide with the hostname.  For hosts serving entire
  230. domains, this is less likely. (Note that in My Setup, I accept mail for
  231. an unofficial mail domain - you won't find an MX record in the DNS for
  232. the delenn.ecs.soton.ac.uk mail domain)
  233.  
  234.  
  235. alias file format
  236. =-=-=-=-=-=-=-=-=
  237.  
  238. The format of the file is that the alias appears first on the line, and
  239. the real addresses are specified after it separated by whitespace.  If
  240. you need to use more than one line, then these continuation lines MUST
  241. start with whitespace (otherwise they are considered to be other aliases)
  242.  
  243. Although this might seem like a good way to set up a mailing list, this
  244. is NOT the case, since the original sender will be in the FROM envelope,
  245. so any forwarding errors will go to there and not to some mailing list
  246. software.
  247.  
  248. The purpose of the alias file is for *simple* rewriting and occasional
  249. duplication if you need it.  If you want to run a mailing list, then
  250. use something like !MailList.
  251.  
  252. So in My Setup mentioned above shows that any mail incoming addressed
  253. to S.N.Brodie@delenn.ecs.soton.ac.uk will be sent to snb94r.  This is
  254. useful because you can specify names which might not be acceptable as
  255. usernames to Newsbase.
  256.  
  257.  
  258.  
  259. forwarder
  260. =========
  261.  
  262. Syntax:   forwarder <"*" | F.Q. Mail Domain> <"MX" | smarthost-FQDN>
  263. Demon DU: forwarder * post.demon.co.uk
  264. Network:  forwarder * MX
  265.           forwarder * mail.smarthost.provider.org
  266. My Setup: forwarder ecs.soton.ac.uk MX
  267.           forwarder * dsse.ecs.soton.ac.uk
  268.  
  269.  
  270. This gives mail domains which are to be responded to by the software, but
  271. which are not local to this machine (ie. they need to forwarded on somewhere
  272. else, cf. localdomain).  For the vast majority of people, you will want one
  273. forwarder line (see WARNING below - having such lines may in fact
  274. contravene your provider's terms & conditions of service unless you have
  275. specifically purchased the right to forward mail).
  276.  
  277. The major purpose of the non-* entries here is when you are running FreeSMTP
  278. on the mail gateway for a domain (ie. the MX record for a domain gives
  279. the machine running FreeSMTP as one of the mail exchangers).
  280.  
  281. If there are no forwarder lines, then any mail not destined for local
  282. delivery (ie. it matched one of the localdomain lines) will be rejected when
  283. it is offered by another host (*).
  284.  
  285. If there are forwarder lines, then they are matched in order.  If the first
  286. parameter is "*", then this matches, otherwise the string has to match the
  287. bit after the @ in the destination of an incoming mail exactly.  The second
  288. parameter describes how this forwarding is to be achieved and is either the
  289. string "MX" or the FQDN of a smarthost which will do the job for you.
  290.  
  291. There are two ways of forwarding the mail - MX records, and smarthosts. Using
  292. MX records involves looking up the name of the machines which handle mail for
  293. a given mail domain (see description later in this document) and then sending
  294. the mail directly to one of those machines.  The alternative is to use a
  295. 'smarthost' (such as post.demon.co.uk) which will perform that function on
  296. your behalf (ie. it acts as an intermediate relay for you). The advantage of
  297. using MX records, is that it bypasses your provider's smarthost (less hops to
  298. the destination) and can tolerate the smarthost being down.  When MX lookups
  299. return multiple records, they are tried in turn according to the priorities
  300. specified by the DNS server. [This does seem to work, as I found out when
  301. Demon's punts weren't accepting mail and when the connection attempt to them
  302. timed out, it sent it to relay-1 instead :-) ]
  303.  
  304. (*) 'another host' could actually be your own machine.  For example, I
  305. have ArcWeb's Email configuration set up with a smarthost mail gateway
  306. of "localhost".  This means that ArcWeb will send mail by talking to the
  307. SMTP server process running on my own machine.  Thus, having no forwarder
  308. lines in my configuration would mean that I couldn't send mail that way
  309. and would have to configure a remote smarthost in ArcWeb instead.
  310.  
  311.  
  312. forwarder strategy
  313. -=-=-=-=-=-=-=-=-=
  314.  
  315. The forwarder directives which specify MX records are to be used are
  316. overridden in some circumstances, primarily for performance reasons.
  317.  
  318. If the mail has only a single recipient (or multiple recipients with the same
  319. domain) and forwarder says to use MX records, and those MX records exist,
  320. then this will happen.
  321.  
  322. If the mail has multiple recipients, then any MX directive is overridden and
  323. a smarthost is used instead *if one is defined* (because otherwise the
  324. message would have to be sent separately to each recipient).  [A future
  325. enhancement will be to still use MX records if all the destinations share a
  326. common mail exchanger]
  327.  
  328.  
  329. WARNING: Incorrect configuration of forwarder records could cause you
  330.          to be in breach of the terms & conditions of your account.
  331.          Unless you are authorised to forward mail to hosts other than
  332.          those at your provider's end of your connection, you should
  333.          only have one forwarder line:
  334.  
  335.         forwarder * post.demon.co.uk
  336.  
  337.          (where you have substituted your provider's smarthost for
  338.          post.demon.co.uk if you aren't with Demon Internet)
  339.  
  340.          The author accepts no responsibility or liability for any
  341.          such breaches of terms & conditions, nor for consequences
  342.          arising from action taken by providers against any user of
  343.          this software for such breaches even if the author has been
  344.          advised of the possibility of such breaches.
  345.  
  346.  
  347. acceptfrom
  348. ==========
  349.  
  350. Syntax:   acceptfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  351. Demon DU: (no acceptfrom lines)
  352. Network:  (no acceptfrom lines)
  353. My Setup: (no acceptfrom lines)
  354.  
  355. ** WARNING: If you use hostnames with this command, then these must be
  356. **          resolvable when the program starts, otherwise the directive
  357. **          will be ignored.
  358.  
  359. This is used to selectively choose which remote hosts you are willing to
  360. accept mail from.  If a host other than one listed attempts to deliver
  361. mail to your machine, then it will be told that it does not have permission
  362. to deliver mail to your machine.  If there are no acceptfrom lines (as in
  363. My Setup) then any host may connect.
  364.  
  365. When specifying an IP address, you may specify the number of significant bits
  366. to be matched (as described in the rejectfrom section below)
  367.  
  368. All addresses that pass the acceptfrom directives (including the case
  369. where there are NO acceptfrom directives) are then validated against
  370. the rejectfrom directives described in the next section.
  371.  
  372. There is little real reason to use this facility unless you are worried about
  373. faked e-mail being sent via your site (and even then, the message is tagged
  374. with the Received line containing the IP address of the sender, allowing you
  375. to trace the source)
  376.  
  377. See also: rejectfrom, killfile
  378.  
  379. rejectfrom
  380. ==========
  381.  
  382. Syntax:   rejectfrom ((<IP address> "/" <significant bits>) | ( FQDN ))
  383. Demon DU: rejectfrom 198.81.0.0/16
  384.           rejectfrom 152.163.172.0/24
  385. Network:  rejectfrom relay.deliverer.hackers.org
  386. My Setup: (no rejectfrom lines)
  387.  
  388. ** WARNING: If you use hostnames with this command, then these must be
  389. **          resolvable when the program starts, otherwise the directive
  390. **          will be ignored.
  391.  
  392. This is used to selectively choose which remote hosts you are NOT willing to
  393. accept mail from.  If a host covered by one of these directives, then it will
  394. be told that it does not have permission to deliver mail to your machine.  If
  395. there are no rejectfrom lines (as in My Setup) then any host may connect
  396. (subject to the acceptfrom conditions).  The Demon DU example describes that
  397. mail from 198.81.xxx.xxx and from 152.163.172.xxx will be rejected (these
  398. are the AOL mail exchangers :-)  I am not suggesting that you do this - just
  399. using it as an example of use.
  400.  
  401. IMPORTANT: You should not reject any of your machine's own IP addresses
  402. (including 127.0.0.1 (localhost)).  See also: acceptfrom, killfile
  403.  
  404. In fact, in the current versions localhost (127.0.0.1) is treated as a
  405. special case and FreeSMTP will not allow you to use it in a rejectfrom
  406. command.  Before version 1.33 this was not the case.
  407.  
  408. There is very little real reason to use this facility unless you have
  409. some hacker trying to send you mail, in which case you can block their
  410. IP address using this facility.
  411.  
  412.  
  413. killfile
  414. ========
  415.  
  416. Syntax:   killfile <Fully Qualified Kill File path name>
  417. Demon DU: killfile smtpserver:killfile
  418. Network:  killfile smtpserver:killfile
  419. My Setup: killfile smtpserver:killfile
  420.  
  421. This is used to kill incoming mail based on the *sender* specified
  422. in the SMTP envelope (ie. the MAIL FROM).  The file named in the
  423. directive is consulted when a new transaction is started and if
  424. the sender matches any entry, the mail is rejected.
  425.  
  426. (You need to restart FreeSMTP after editing the killfile in order for any new
  427. entries to take effect)
  428.  
  429. The kill file format itself is one (wildcardable) address per line.
  430. If the kill file does not exist, nothing is killed.
  431.  
  432. Version 1.34 and later allow you to use "reversed" kills which act as a green
  433. light for a particular sender.  This can be used to allow through a specific
  434. sender (or range of senders - you can use wildcards just like other
  435. entries) by overriding a killfile entry that has a wider scope.  Reverse
  436. kills are denoted by an exclamation mark followed by a space and then the
  437. address as usual.  For example:
  438.  
  439. ! myFriend@hotmail.com
  440. *@hotmail.com
  441.  
  442. The first line "unkills" mail from myFriend@hotmail.com whilst e-mail from
  443. anything else @hotmail.com is still rejected.
  444.  
  445.  
  446.  
  447. vaguemessages
  448. =============
  449.  
  450. Syntax:   vaguemessages
  451. Demon DU:
  452. Network:
  453. My Setup:
  454.  
  455. This directive is optional and takes no parameters. This is used to control
  456. the message returned to the sender when the incoming mail is being rejected
  457. due to it having matched a killfile entry. If this directive is present, the
  458. response is "550 Mailbox does not exist - sorry".  If it is not, then it
  459. replies "550 Sender <sender's address> rejected by local policy".
  460.  
  461.  
  462. noexpand
  463. ========
  464.  
  465. Syntax:   noexpand
  466. Demon DU:
  467. Network:  noexpand
  468. My Setup:
  469.  
  470. This directive is optional and takes no parameters.  If it is present,
  471. then clients attempting an EXPN on an alias will receive a message
  472. indicating that EXPN has been explicitly disabled by the administrator.
  473.  
  474. If you don't understand the above paragraph, then you don't need this.
  475.  
  476. Normally, you'd only use this to stop people looking up the members of
  477. a mailing list of something like that.  The vast majority of people
  478. do not want this.
  479.  
  480.  
  481. noident
  482. =======
  483.  
  484. Syntax:   noident
  485. Demon DU:
  486. Network:  noident
  487. My Setup:
  488.  
  489. This directive is optional and takes no parameters.  If it is present,
  490. then the server will not attempt an ident request to the client making
  491. the connection.  See "Remote User Authentication" section below for
  492. more details of ident.
  493.  
  494. If you don't understand the above paragraph, then you don't need this.
  495.  
  496. You would only ever disable this feature for efficiency reasons.
  497.  
  498. noiconbar
  499. =========
  500.  
  501. Syntax:   noiconbar
  502. Demon DU: noiconbar
  503. Network:
  504. My Setup:
  505.  
  506. This directive is optional and takes no parameters.  If it is present,
  507. then no icon bar icon will be installed.
  508.  
  509. You would only ever disable this feature to avoid filling your iconbar.
  510. If you have this directive, the only way to stop FreeSMTP is to double-
  511. click on FreeSMTP again.
  512.  
  513.  
  514. maxhops
  515. =======
  516.  
  517. Syntax:   maxhops <maximum hop count>
  518. Demon DU:
  519. Network:
  520. My Setup:
  521.  
  522. This directive is optional and defaults to "maxhops 30".  The numeric
  523. parameter describes the maximum number of servers through which the mail is
  524. allowed to be passed before being returned to the sender as undeliverable.
  525. Usually, mail will take at most half a dozen hops to get to the recipient.
  526. If it is up to something more like 30 (the default here), then it is likely
  527. that a mail loop has developed (a set of servers (mis)configured to route
  528. mail for the destination domain to each other, which will just keep
  529. forwarding it back and forth forever and ever).  Once maxhops is exceeded,
  530. this server will not forward it any more, but will construct a delivery
  531. failure message and bounce it back to the sender.
  532.  
  533. Almost certainly, you do not want to override the default.
  534.  
  535.  
  536. maxsessions
  537. ===========
  538.  
  539. Syntax:   maxsessions <+ve integer>
  540. Demon DU: maxsessions 4
  541. Network:  maxsessions 4
  542. My Setup: maxsessions 4
  543.  
  544. This specifies the maximum number of sessions that may be in progress at
  545. any one time.  This is limited by the capability of the C library (and if
  546. you specify a number too large, it will be reduced to the maximum that can
  547. be supported - 4 with the current SharedCLibrary.
  548.  
  549. It is important to have this set to 4 for Demon customers, since Demon
  550. have multiple mail machines which may attempt delivery concurrently.
  551.  
  552.  
  553. Why does all email get sent to "localhost"
  554. ------------------------------------------
  555.  
  556. All e-mail sent by your machine will be sent initially to the server on your
  557. machine.  (tech: the GATE command in the work file will always be set up
  558. to be "GATE VIA:localhost").  This is deliberate, because all the mail
  559. routeing cleverness is stored in the *server* at the moment.  That software
  560. can then make the final destination decision and requeue it for sending out.
  561.  
  562. This will cause an extra Received header to be placed in the outgoing mail,
  563. and will also ensure that missing headers are inserted before the mail
  564. leaves your machine too.
  565.  
  566. This is not a really peculiar thing to do.  Most UNIX machines I have used
  567. have done this.  It is done to simplify the coding of the mail senders
  568. (and make them smaller!) and to centralise the decision making process and
  569. forwarding rule processing into a single place so that policy changes can be
  570. implemented in one go.
  571.  
  572.  
  573. Operating Advice
  574. ----------------
  575.  
  576. for people with permanent connections
  577. =====================================
  578.  
  579. Run it all the time - that's what I do.  The performance of your machine
  580. should not be affected at all when it is idle.
  581.  
  582.  
  583. for people with transient dialup links
  584. ======================================
  585.  
  586. You really do want to start the TCP/IP stack and !FreeSMTP *before*
  587. connecting to the net.  This is particularly important for Demon users, since
  588. the SMTP server takes around 1 second to start up and read its configurations
  589. files and may not manage to start listening for the incoming connections
  590. before the punts attempt to deliver mail (they fail to do so, and hold on to
  591. it for a while before trying again a bit later).  This causes a slight
  592. problem with dialup lines though unless you are careful.  You *must* start
  593. the TCP/IP stack, but you do NOT need to start up the SLIP/PPP interface (if
  594. you do, your dialler won't be able to access the comms port!).  The relevant
  595. bits that must be deferred until after dialling is complete are the slattach
  596. & ifconfig commands.
  597.  
  598. Beware that this means acceptfrom & rejectfrom directives cannot use
  599. hostnames if you do this (because the DNS server will not be reachable until
  600. the link is up).
  601.  
  602.  
  603. Running & Stopping !FreeSMTP
  604. ----------------------------
  605.  
  606. Run !FreeSMTP by double-clicking on the icon in the directory viewer.
  607. To stop, it double-click on the icon again (or kill SMTP Monitor in
  608. the Task display window) or choose Quit from the icon bar menu if you
  609. haven't disabled the Wimp interface (see "noiconbar" directive above)
  610.  
  611.  
  612. What to do if you get the error message:
  613.     Loopback interface is not configured/up
  614.     Loopback interface is configured - but not up
  615. -----------------------------------------------------
  616.  
  617. These two messages are new in version 1.17.  If you get them, then you
  618. will find that the program will not have started.  FreeSMTP needs the
  619. loopback interface configured.  This should have been done during your
  620. boot sequence, or whenever the TCP/IP networking software was loaded.
  621.  
  622. If you get the latter of the messages (which would be unusual unless
  623. you were fiddling around), then you need to issue the command:
  624. "*ifconfig lo0 up" at the command line or insert this in the networking
  625. startup files.
  626.  
  627. If you get the former, then you need to insert the slightly longer:
  628. "*ifconfig lo0 inet 127.0.0.1 up".
  629.  
  630. Once these commands have been executed, FreeSMTP should load.   If it
  631. still doesn't, then the chances are you that are using an old version of
  632. FreeNet.  Edit !FreeSMTP.!Run and insert the following line:
  633.  
  634. Set SMTPServer$NoSearch 1
  635.  
  636.  
  637. (See also: Why does all email get sent to "localhost")
  638.  
  639.  
  640.  
  641. Kicking the sender
  642. ------------------
  643.  
  644. The sender program (out_smtpd) is automatically launched (by SMTP Monitor)
  645. after in_smtpd has queued a mail in the outgoing queue, or the sendmail
  646. Newsbase transport has queued a mail there.  You can kick it by choosing
  647. "Kick" on the icon bar menu (see "noiconbar" directive) or double-clicking on
  648. !SendSMTP (inside !FreeSMTP).
  649.  
  650. After being loaded, it will wait 5 minutes between automatic kicks of the
  651. sender process.  The 5 minute timer is reset if you kick FreeSMTP manually.
  652.  
  653.  
  654. Activity Log
  655. ------------
  656.  
  657. This software contains inbuilt activity logging which it will dump to the
  658. Syslog application. The amount of debugging and which debugging is controlled
  659. by a file called area_log inside !FreeSMTP.  This contains one string per
  660. line containing a case-sensitive string to match against those used in the
  661. code.  (* is used as a wildcard which matches every string).  Examples of
  662. these are:
  663.  
  664.     domain_init
  665.     process_mail
  666.     verify_dest
  667.  
  668. Vital messages are always logged if possible.
  669.  
  670. If you place a line containing just a single * character in this file, then
  671. everything will be logged to this file, this will help provided more details
  672. if you are having problem.  If you send me this file when reporting faults,
  673. then it is more likely that I shall be able to help.  If you do this, then
  674. the log file will grow very quickly.  Only use it when attempting to capture
  675. debug trails for me.
  676.  
  677.  
  678. References
  679. ----------
  680.  
  681. RFC821 - Simple Mail Transfer Protocol
  682.  
  683. RFC1123 - Requirements for Internet Hosts
  684.  
  685. RFC1413 - Identification Protocol
  686.  
  687.  
  688. Bug Reporting
  689. -------------
  690.  
  691. There are bug reporting features built-in to the software.  If you edit
  692. the file !FreeSMTP.area_log and add a new line at the bottom containing
  693. just an asterix (*), then all debugging information will be sent to the
  694. files, and not just the really important ones.  These document some of
  695. the decisions made by the software and will contain justification for
  696. those decisions.
  697.  
  698. Please give as much detail as possible when reporting bugs.  Include the
  699. e-mail message that caused the problem if possible.  NOTE:  If you do not
  700. wish to disclose the identities of the sender/recipient, then please feel
  701. free to overwrite it with something else - use * characters for example -
  702. but please do NOT just remove it.  If you do choose to delete parts of it,
  703. then please only delete the bits before the @ in the address.  You may
  704. also like to remove most of the message body.
  705.  
  706. Bug reports to stewart@eh.org please.
  707.  
  708.  
  709. Technical Details
  710. -----------------
  711.  
  712. I have included this section for those who are interested.  It does not
  713. matter if you do not want to read any more of this document.
  714.  
  715. MX Records Explained
  716. ====================
  717.  
  718. Briefly.  You are probably familiar with the concept of hostnames (eg.
  719. customer.demon.co.uk, www.demon.co.uk, sunsite.doc.ic.ac.uk).  The mappings
  720. between these and the 4 byte numeric IP addresses (eg. 152.78.67.42) are
  721. registered in the Domain Name System's 'A' records (A for address).  Mail
  722. domains look very much like hostnames, and in some cases happen to be the
  723. same, but this is coincidence (but arranged like that because it's easier to
  724. remember :-)   Mail domains are also registered in the Domain Name System,
  725. but they do NOT map to IP addresses, but to 'Mail eXchangers'.  These mail
  726. exchangers are simply the hostnames of machines which handle mail for that
  727. mail domain.  For example, when software is using MX records to send mail to
  728. my (now obsolete!) university e-mail address, it looks up the MX records for
  729. 'ecs.soton.ac.uk'.  The response it will get will be something similar to:
  730.  
  731. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  732. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  733.  
  734. This indicates that bright.ecs.soton.ac.uk (which when looked up, is found to
  735. have the address 152.78.64.201) is a machine which handles mail for
  736. 'ecs.soton.ac.uk'.  landlord.ecs.soton.ac.uk is also reported as a mail
  737. exchanger (so when bright is down, we can still receive mail), but the lower
  738. number indicates that bright is the preferred exchanger, and landlord the
  739. backup.  If you perform a similar lookup on any Demon customer domain,
  740. usually you will find 4 or 5 records, with varying priorities.  Although it
  741. would appear that lots of DNS lookups are required in order to find the
  742. addresses of these mail exchangers, that is not the case typically, as the
  743. full response from the DNS for the question "ecs.soton.ac.uk IN MX" will be
  744. (if not querying one of our authoritative nameservers in Southampton):
  745.  
  746. Questions:
  747. ecs.soton.ac.uk. IN MX
  748.  
  749. Answers:
  750. ecs.soton.ac.uk. IN MX 5 bright.ecs.soton.ac.uk.
  751. ecs.soton.ac.uk. IN MX 10 landlord.ecs.soton.ac.uk.
  752.  
  753. Additional:
  754. bright.ecs.soton.ac.uk IN A 152.78.64.201
  755. landlord.ecs.soton.ac.uk IN A 152.78.114.230
  756.  
  757. Authority records:
  758. dns0.ecs.soton.ac.uk    inet address = 152.78.64.201
  759. dns1.ecs.soton.ac.uk    inet address = 152.78.114.230
  760. dns0.brad.ac.uk inet address = 143.53.240.2
  761. dns0.brad.ac.uk inet address = 143.53.2.5
  762. dns1.brad.ac.uk inet address = 143.53.238.5
  763.  
  764. ie. since it is assumed that you will probably want the IN A record for
  765. each mail exchanger, the DNS server includes those records in its answer
  766. which you may need.  Since you may not 'trust' the nameserver, it also tells
  767. you machines that are the authoritative DNS servers for the ecs.soton.ac.uk
  768. internet domain.  The auth records show the names of our primary and
  769. secondary DNS servers, plus our offsite authority nameserver (an Internet
  770. requirement) at Bradford.
  771.  
  772.  
  773. Remote host authentication
  774. ==========================
  775.  
  776. When a connection is accepted, the peer IP address is looked up in the DNS.
  777. Since this lookup is initiated immediately, then the lookup is often
  778. complete before the HELO arrives (and the HELO parameter can thus be
  779. authenticated immediately).  The domain name specified as the parameter to
  780. HELO is used in the Received header which is added by the smtp server to
  781. the incoming message, together with either the IP address of the remote
  782. host, or the name as obtained from the DNS.
  783.  
  784. NOTE: Mail will NOT be rejected if the HELO domain fails to authenticate.
  785. This is RFC-compliant behaviour (it is not allowed to reject on the basis
  786. of the HELO domain).
  787.  
  788.  
  789. Remote user authentication
  790. ==========================
  791.  
  792. When a connection is accepted, then an ident request is sent to the origin
  793. machine requesting the user identity of the sender.  (This is not done if
  794. the configuration file contains a "noident" directive).  This is logged
  795. with area "ident" (so place "ident" in area_log to see it)
  796.  
  797. NOTE: You cannot rely on this, particularly on the user id returned. See
  798. RFC1413 for more details about the (lack of) confidence that you should
  799. have in the ident response.
  800.  
  801. NOTE 2: You might decide to disable this, but usually only because the
  802. overhead of establishing a TCP connection to the client wastes resources.
  803. The bandwidth used is negligible though (on average about 10 bytes out,
  804. and 25-50 bytes back).
  805.  
  806.  
  807. Attacks & Security Considerations
  808. =================================
  809.  
  810. Simple denial of service attacks are prevented (limits on number of
  811. recipients for message plus limits on number of concurrent connections)
  812. The recipient limit is set to 100 (minimum requirement in RFC821)
  813.  
  814. Idling attacks are repelled by implementing the timeout strategy given
  815. in RFC1123.
  816.  
  817. Well faked e-mail can never be detected successfully, but the addition
  818. of the Received header to incoming message bodies will assist in the
  819. tracing of injection points into the SMTP system.
  820.  
  821. For the general mail security considerations see RFC821 and RFC1123.  In
  822. the RISC OS environment, a further consideration is that being a single-
  823. user operating system, there is no way to prevent the Newsbase being
  824. examined directly, or the outgoing queue to be examined, unless you have
  825. taken specific measures to make this so.
  826.  
  827. RFC1123 Considerations
  828. ======================
  829.  
  830. Incoming addresses in both MAIL FROM and RCPT TO fields are automatically
  831. rewritten as per RFC1123 to strip unnecessary source routeing from them.
  832. This happens before any other processing.  (This also has the effect of
  833. stopping hackers using source routeing as a way of using you as a mail
  834. gateway, since after the rewrite, the destination domain will no longer
  835. match a localdomain, and will be rejected unless you forward for that
  836. domain)
  837.  
  838. The %-hack is supported by the address rewriter too and explicitly
  839. removed, so hackers can't use that either.
  840.  
  841. Miscellaneous
  842. =============
  843.  
  844. When spooling files if the file cannot be opened in spool.mail.text.user then
  845. spool.fail.user is used instead (and the mail is bounced if that fails too).
  846. Files in spool.fail.user are never touched again and need to be handled
  847. manually.
  848.  
  849. I am very interested in RFC compliancy issues. E-mail
  850. me any issues you find.
  851.  
  852.  
  853. Recent ChangeLog
  854. ================
  855.  
  856.  
  857. 1.37
  858. ----
  859.  
  860. Doesn't resubtract the timezone offset from already correct UTC dates.
  861.  
  862.  
  863. 1.36
  864. ----
  865.  
  866. More assembler code removed, plus date processing code made independent
  867. of the current territory.
  868.  
  869.  
  870. 1.35
  871. ----
  872.  
  873. The call to read the monotonic timer was always returning zero due to
  874. a MOVVC a1, #0 (should have been MOVVS a1, #0) :-/   This stopped
  875. various timed things from working properly, notably idle-out, auto-kick.
  876.  
  877.  
  878. 1.34
  879. ----
  880.  
  881. Reverse kills added.
  882.  
  883.  
  884.  
  885.  
  886. Please e-mail me any problems: stewart@eh.org
  887.  
  888.  
  889. --
  890. Stewart Brodie
  891. August 1998
  892.